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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3' Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document defines the Radio Network Layer user plane protocol being used over the lu interface. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[I] 3GPP TS 25.401: "3"* Generation Partnership Project (3GPP) Technical Specification Group 
(TSG) RAN; UTRAN Overall Description". 

[2] 3GPP TS 25.410: "3"* Generation Partnership Project (3GPP) Technical Specification Group 

(TSG) RAN; UTRAN lu interface: general Aspects and Principles". 

[3] 3GPP TS 25.413: "3"* Generation Partnership Project (3GPP) Technical Specification Group 

(TSG) RAN; UTRAN lu interface RANAP protocol". 

[4] 3GPP TS 25.414: "3"* Generation Partnership Project (3GPP) Technical Specification Group 

(TSG) RAN; lu Interface Data Transport and Transport Signalling". 

[5] 3GPP TS 23.1 10: "3''' Generation Partnership Project (3GPP) Technical Specification Group 

(TSG) SSA, UMTS Access Stratum, services and functions". 

[6] 3GPP TS 23. 121 : "3"* Generation Partnership Project (3GPP) Technical Specification Group 

(TSG) SSA, Architectural requirements for Release 99". 

[7] ITU-T Recommendation 1.363.2 (1997): "B-ISDN ATM Adaptation Layer type 2 specification". 

[8] ITU-T Recommendation 1.366.1 (1998): "Segmentation and reassembly service specific 

convergence sublayer for the AAL type 2". 

[9] 3GPP TR 25.990: "3"* Generation Partnership Project (3GPP) Technical Specification Group 

(TSG) RAN; Vocabulary". 

[10] 3GPP TS 25.321: "3"* Generation Partnership Project (3GPP) Technical Specification Group 

(TSG) RAN; MAC Protocol Specification". 

[II] 3GPP TS 25.322, 3"* Generation Partnership Project (3GPP) Technical Specification Group (TSG) 



RAN; RLC Protocol Specification. 

3GPP TS 26.102: "3"* Generation P; 

(TSG) SA; Mandatory speech codec; AMR speech codec; Interface to lu and Uu". 



[12] 3GPP TS 26.102: "3"* Generation Partnership Project (3GPP) Technical Specification Group 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

lu Timing Interval (ITI): lu Timing Interval is the minimum time interval between sent lu UP PDUs for a specific 
RAB. The ITI can be calculated for conversational and streaming traffic classes by the following formula: 

_ MaxSDUsize 
MaxBitrate 

Inter PDU Transmission Interval (IPTI): Inter PDU Transmission Interval is the actual interval at wich lu UP PDUs 
can be sent at a certain time for a specific RAB. The IPTI of a RAB is calculated based on the RAB sub flow 
combination size and the RAB subflow combination bitrate by dividing the RAB subflow combination size with the 
RAB subflow combination bitrate. 

RFC _ size 

IPTI = — , p = l,...,n, n = number of subflowcombinations 

' RFC Bitrate„ 



NOTE: If RFC_Bitrate is not defined then IPTI=ITI. If RFC_size is not defined then RFC_size=MaxSDUsize. 

Non Access Stratum (NAS) Data Streams: non Access Stratum Data Streams is a generic term to identify these data 
streams exchanged at the Dedicated Service Access Points between the Non Access Stratum and the Access Stratum. 

RAB sub-flows: RAB as defined in [9] is realised by UTRAN through one to several sub-flows. These sub-flows 
correspond to the NAS service data streams that have QoS characteristics that differ in a predefined manner within a 
RAB e.g. different reliability classes. 

RAB sub-flows characteristics: 

1) the sub-flows of a RAB are established and released together at the RAB establishment and release, respectively; 

2) the sub-flows of a RAB are submitted and delivered together at the RAB SAP; 

3) the sub-flows of a RAB are carried over the same lu transmission connection; 

4) the sub-flows of a RAB are organised in a predefined manner at the RAB SAP and over the lu interface. The 
organisation is imposed by the NAS as part of its co-ordination responsibility. 

RAB sub-flows numbering (applies to support mode for predefined SDU size only): 

1) RAB sub-flows are numbered from 1 to N (N is the number of sub-flows); 

2) RAB sub-flow number 1 corresponds to the highest reliability class and the RAB sub-flow number N 
corresponds to the lowest reliability class; 

3) RAB sub-flows order inside the lu frame is predefined so that RAB sub-flow number one comes first and the 
RAB sub-flow number N comes last. 

RAB sub-Flow Combination (RFC): RAB sub-flow combination is defined as an authorised combination of the RAB 
sub-flows variable attributes (e.g. SDU sizes) of currently valid RAB sub-flows that can be submitted simultaneously to 
the lu UP for transmission over lu interface. Each combination is given by the CN and cannot be altered by the SRNC. 

RAB sub-Flow Combination Indicator (RFCI): this indicator uniquely identifies a RAB sub-flow combination for 
the duration of the lu UP peer protocol instances i.e. it is valid until the termination of the call or until a new 
initialisation is performed. Usage of RFCI applies only to lu UP protocol operated in support mode for predefined SDU 
size. 
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Principles related to RFCI allocation and initialisation procedure: 

1) RFCI value is present in every lu user frame; 

2) in the Initialisation procedure in lu UP, the size of every RAB sub-flow SDU for each RFCI is signalled. 

Syntactical error: field is defined to be syntactically incorrect in a message if it contains at least one value defined as 
"reserved", or if its value part violates syntactic rules given in the specification of the value part. However it is not a 
syntactical error that a value specified as "spare" is being used. 

Semantical error: message is defined to have semantically incorrect contents if it contains information which, possibly 
dependant on the state of the receiver, is in contradiction to the resources of the receiver and/or to the procedural part. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AMR Adaptive Multi-Rate codec 

AS Access Stratum 

CN Core Network 

DTX Discontinuous Transmission 

GF Galois Field 

IPTI Inter PDU Transmission Interval 

ITI lu Timing Interval 

NAS Non Access Stratum 

PCE Procedure Control Extension 

PDU Protocol Data Unit 

PME Procedure Control Bitmap Extension 

QoS Quality of Service 

RAB Radio Access Bearer 

RANAP Radio Access Network Application Part 

RFC RAB sub Flow Combination 

RFCI RFC Indicator 

RNL Radio Network Layer 

SAP Service Access Point 

SDU Service Data Unit 

SMpSDU Support Mode for predefined SDU size 

SRNC Serving RNC 

SRNS Serving RNS 

SSSAR Service Specific Segmentation And Reassembly 

TFI Transport Format Identification 

TFO Tandem Free Operation 

TNL Transport Network Layer 

TrFO Transcoder Free Operation 

TrM Transparent Mode 

UP User Plane 

UUI User to User Information 

3.3 Concepts 

lu UP mode of operation: 

One objective of the lu User Plane (UP) protocol is to remain independent of the CN domain (Circuit Switched or 
Packet Switched) and to have limited or no dependency with the Transport Network Layer. Meeting this objective 
provides the flexibility to evolve services regardless of the CN domain and to migrate services across CN domains. 

The lu UP protocol is therefore defined with modes of operation that can be activated on a RAB basis rather than on a 
CN domain basis or (tele)service basis. The lu UP mode of operation determines if and which set of features shall be 
provided to meet e.g. the RAB QoS requirements. 

lu UP protocol PDU Type: 
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The lu UP protocol PDU Types are defined for a given lu UP mode of operation. An lu UP PDU Type represents a 
defined structure of an lu UP protocol frame. For instance, a frame made of a certain Frame Header mask part and a 
Frame Payload part would be specified as a certain PDU type valid for a given lu UP mode of operation. 

Tandem Free Operation (TFO): 

Configuration of a Speech or Multimedia call for which Transcoders are physically present in the communication path 
but transcoding functions are disabled or partially disabled. The Transcoders may perform control and/or protocol 
conversion functions. 

Transcoder (TC): 

Physical device present in the network responsible for the transcoding of the speech data between two speech codecs or 
coding schemes (The Transcoder may also include other functions, i.e. Rate Adaptation in GSM). 

Transcoder Free Operation (TrFO): 

Configuration of a Speech or Multimedia call for which Transcoders are not present in the communication path. 



4 General 

4.1 General aspects 

The lu UP protocol is located in the User plane of the Radio Network layer over the lu interface: the lu UP protocol 
layer. 

The lu UP protocol is used to convey user data associated to Radio Access Bearers. 

One lu UP protocol instance is associated to one RAB and one RAB only. If several RABs are established towards one 
given UE, then these RABs make use of several lu UP protocol instances. 

lu UP protocol instances exist at lu access point as defined [2] i.e. at CN and UTRAN. Whenever a RAB requires 
transfer of user data in the lu UP, an lu UP protocol instance exists at each lu interface access points. These lu UP 
protocol instances are established, relocated and release together with the associated RAB. 

Whether these peer protocol instances perform some RAB related function depends on the mode of operation of the lu 
UP as defined below. 

The following figure illustrates the logical placement of the lu UP protocol layer and the placement of the Data Streams 
sources outside of the Access Stratum. 
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Figure 1 : lu UP protocol layer occurrence in UTRAN overall architecture (User Plane View) 
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4.2 Operational and Functional aspects 

4.2.1 lu UP protocol modes of operation 

The lu UP protocol operates in mode according to the concept described in earlier subclause. 
Modes of operation of the protocol are defined: 

1) Transparent mode (TrM); 

2) Support mode for predefined SDU size (SMpSDU). 

Determination of the lu UP protocol instance mode of operation is a CN decision taken at RAB establishment based on 
e.g. the RAB characteristics. It is signalled in the Radio Network layer control plane at RAB assignment and relocation 
for each RAB. It is internally indicated to the lu UP protocol layer at user plane establishment. 

The choice of a mode is bound to the nature of the associated RAB and cannot be changed unless the RAB is changed. 

4.2.2 Transparent mode (TrIVI) 

The transparent mode is intended for those RABs that do not require any particular feature from the lu UP protocol 
other than transfer of user data. 

The following figure illustrates the transparent mode of operation of the lu UP protocol layer. 



UTRAN 



lu Interface 




lu UP layer in 
transparent mode 




RNL-SAP, 




CN 



Won Access 
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Access Stratum 



lu UP layer in 
transparent mode 



Figure 2: lu UP protocol layer in transparent occurrence over lu interface 

In this mode, the lu UP protocol instance does not perform any lu UP protocol information exchange with its peer over 
the lu interface: no lu frame is sent. The lu UP protocol layer is crossed through by PDUs being exchanged between 
upper layers and transport network layer. 

For instance, the transfer of GTP-U PDUs could utilise the transparent mode of the lu UP protocol. 

4.2.3 Support mode 

The support modes are intended for those RABs that do require particular features from the lu UP protocol in addition 
to transfer of user data. When operating in a support mode, the peer lu UP protocol instances exchange lu UP frames 
whereas in transparent mode, no lu UP frames are generated. 
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The following figure illustrates the functional model of the lu UP protocol layer in support mode of operation. 
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Figure 3: lu UP protocol layer in support mode occurrence over lu interface 

Some RABs requesting lu UP protocol support, constrain the lu UP protocol and possibly the radio interface protocols 
in specific ways. For instance, certain RABs can have variable predefined rates. 

The lu UP support mode is prepared to support variations. 

The only support mode defined here is the: 

support mode for predefined SDU size (SMpSDU). 

For instance, the transfer of AMR speech PDUs would utilise the support mode for predefined SDU size of the lu UP 
protocol because it requires some procedure control functions and some data streams specific functions while the sizes 
of the user data being transferred can vary in a predefined manner. 



Transparent mode, version 1 



5.1 



General 



5.1 .1 Operation of the lu UP in Transparent mode 

The lu UP layer in Transparent mode is present in the lu User plane for transferring data transparently over the lu 
interface. 

The two strata communicate through a Service Access Point for Non Access Stratum (NAS) Data Streams transfer. 

5.1 .2 Interfaces of the lu UP protocol layer in Transparent mode 

Interfaces of the lu UP protocol layer in transparent mode are the transport network layer and the upper layers. The lu 
UP protocol layer in Transparent Mode is an empty layer through which NAS Data Streams PDUs are crossing between 
the Transport Network Layer and upper layers. 

The lu UP protocol layer in transparent mode is using services of the Transport layers in order to transfer the lu UP 
PDUs over the lu interface. 
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5.2 lu UP Protocol layer Services in Transparent mode 

The following functions are needed to support this mode: 
transfer of user data. 

5.3 Services Expected from the UP Data Transport layer 

The lu UP protocol layer in Transparent mode expects the following services from the Transport Network Layer: 
transfer of user data. 

5.4 Elements for lu UP communication in Transparent mode 
5.4.1 Frame Format for transparent mode 

The following shows the format of the PDU crossing the lu UP protocol layer in transparent mode. This frame is 
transferred transparently between the lu UP protocol upper layers and transport network layer (TNL-SAP). 



Oct1 




Octn 



Figure 4: Frame format for transparent mode 

This PDU has a variable length of n octets, whose maximum range depends on the type of user data (e.g. IP packet). No 
explicit length indication is visible at the lu UP protocol layer. 



Support mode for predefined SDU sizes, version 1 



6.1 



General 



6.1 .1 Operation of the lu UP in Support mode 

The lu UP protocol layer in Support mode is present for data streams that need frame handling in the UP. 

The two strata communicate through a Service Access Point for Non Access Stratum (NAS) Data Streams transfer. 

6.1 .2 Interfaces of the lu UP protocol layer in Support mode 

As part of the Access Stratum responsibility, the lu UP protocol layer in support mode provides the services and 
functions that are necessary to handle non access stratum data streams. The lu UP protocol layer in support mode is 
providing these services to the UP upper layers through a Dedicated Service Access Point used for Information Transfer 
as specified in [5]. 

The lu UP protocol layer in support mode is using services of the Transport layers in order to transfer the lu UP PDUs 
over the lu interface. 
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6.2 lu UP Protocol layer Services in Support mode 



Support mode for predefined SDU size Service 

The following functions are needed to support this mode: 
transfer of user data; 
initialisation; 
rate control; 
time alignment; 
handling of error event; 
frame quality classification. 



6.3 Services Expected from the UP Data Transport layer 

The lu UP protocol layer expects the following services from the Transport Network Layer: 
transfer of user data. 



6.4 Functions of the lu UP Protocol Layer in Support mode 
6.4.1 Functional model of the lu UP Protocol Layer in Support mode 
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Figure 5: Functional model of the lu UP protocol layer in Support mode 

The lu UP protocol layer in Support mode is made of three sets of functions: 

1) Frame Handler function; 

2) Procedure Control functions; 

3) Non Access Stratum Data Streams specific functions. 
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6.4.2 Frame Handler function 

This function is responsible for framing and de-framing the different parts of an lu UP protocol frame. This function 
takes the different parts of the lu UP protocol frame and set the control part field to the correct values, including the 
handling of the frame number. It also ensures that the frame control part is semantically correct. This function is 
responsible for interacting with the Transport layers. This function is also responsible for the CRC check of the lu UP 
frame header. The lu UP frame with header CRC check error is discarded. 

6.4.3 Procedure Control functions 

This set of functions offers the control of a number of procedures handled at the lu UP protocol level. These functions 
are responsible for the procedure control part of the lu UP frames. 

Namely, these procedures are: 

Rate Control: is the procedure which controls over the lu UP the set of permitted rates among the rates that can 
be controled. The set of rates is represented by RFCI indicators and (when applicable) downlink send intervals. 
The function controlling this procedure interacts with functions outside of the lu UP protocol layer. 

Initialisation: is the procedure which controls the exchange of initialisation information that is required for 
operation in support mode for predefined SDU size. Such information can contain the RFCI Set to be used until 
termination of the connection or until the next initialisation procedure. This procedure is also used for 
negotiating the version of the lu UP Mode requested for the related RAB. 

Time Alignment: is the procedure that controls the timing of the downlink data to the RNC over lu. The 
function controlling this procedure interacts with functions outside of the lu UP protocol layer. 

Handling of Error Event: is the procedure that controls the information exchanged over the lu related to 
detection of a fault situation. The function controlling this procedure interacts with functions outside of the lu 
UP protocol layer. 

6.4.4 Non Access Stratum Data Streams specific function(s) 

These functions are responsible for a "limited manipulation" of the payload and the consistency check of the frame 
number. If a frame loss is detected due a gap in the sequence of the received frame numbers (for a RAB where frame 
numbers does not relate to time), this shall be reported to the procedure control function. These functions are 
responsible for the CRC check and calculation of the lu UP frame payload part. These functions are also responsible for 
the Frame Quality Classification handling as described below. 

These functions interact with the upper layers by exchanging lu data stream blocks of lu UP frame payload. These 
functions also handles the padding and depadding of the lu UP frame payloads when needed. 

These functions interact with the procedure control functions. 

These functions provide service access to the upper layers for the procedure control functions. 

6.4.4.1 Frame Quality Classification function 

6.4.4.1.1 General 

On the lu UP in Support Mode the frames are classified with the Frame Quality Classifier (FQC). This classifying is 
based on the radio frame classification and the setting of the RAB attributes 'Delivery of erroneous SDUs'. The RAB 
attribute 'Delivery of erroneous SDUs' tells if erroneous frames shall be delivered or not. 

Figure 6 below shows the main input and output information for frame quality classification function on the lu UP. 
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6.4.4.1.2 



Figure 6: Frame quality classification in lu UP 



Handling of FQC information 



In SRNC on the sending side, the Support Mode Functions takes as input the radio frame quahty information together 
with the frame. Based on this, the FQC is set for the frame, a CRC is added, if needed and the frame is sent to CN. The 
following table shows the FQC field setting. 



Table 1 : FQC handling in RNC on uplink 



INPUT 
(for each subflow) 


ACTION 
(on lu UP frame) 


Delivery of 
erroneous SDUs 


Radio Frame 
Classification 


Action tal<en in SRNC 
on the sending side 


Yes 


Bad 


Set FQC to 'bad radio' 


No 


Bad 


Frame not sent 


no-error-detection- 
consideration 


Any value 


Set FQC to good 


Any value 


Good 


Set FQC to good 



In the table above if for any of the subflows the 'Delivery of erroneous SDUs' is set to 'No' and for that subflow the 
Radio frame classification is 'Bad' then the lu UP frame shall not be sent. 

The Support Mode Functions in CN on the receiving side makes a CRC check of the frame payload, if CRC is present 
and passes the frame and the frame quality classification information through the RNL-SAP. 
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Table 2: FQC handling in CN on uplink 



INPUT 


ACTION 
(on lu UP frame) 


Delivery of 

erroneous SDUs 

(for each subflow) 


Payload CRC 

check result 

(on lu UP frame) 


Actions taken at CN on 
the receiving side 


Yes (at least one of 
the subflows have 
this value but none 
have 'No') 


Not OK 


Frame forwarded with 
FOG set to 'bad' 


No (at least one of 
the subflows have 
this value) 


Not OK 


Drop frame, send lu-UP- 
Status primitive 
indicating 'No data' at the 
RNL-SAP 


no-error-detection- 
consideration (All 
subflows have this 
value) 


Any result 


Frame forwarded with 
FQC as set by UTRAN 


Any value 


OK 


Frame forwarded with 
FQC as set by UTRAN 



The Support Mode Functions in CN on the sending side adds a CRC, if necessary to the frame payload and passes it 
together with the FQC (in the transcoded case always set to good). 

The Support Mode Functions in SRNC then makes a CRC -check, if CRC present. Based on the received FQC and 
eventually the CRC check, decision is made whether to deliver the frame or not. 

Table 3: FQC handling in RNC on downlink 



INPUT 


ACTION 
(on lu UP frame) 


Delivery of 

erroneous SDUs 

(for each subflow) 


FQC 
(on lu 

UP 
frame) 


CRC check 
(if payload 

CRC 

present) 

(on lu UP 

frame) 


Actions taken at 
SRNC on the 
receiving side 


Yes 


Bad 


Any result 


Drop frame 


No 


Bad 


Any result 


Drop frame 


Yes 


Bad 

radio 


Any result 


Drop frame 


No 


Bad 

radio 


Any result 


Drop frame 


Yes 


Any 
value 


Not OK 


Drop frame 


No 


Any 
value 


Not OK 


Drop frame 


no-error-detection- 
consideration 


Any 
value 


Any result 


Pass the frame to 
radio interface 
protocols 


Any value 


Good 


OK 


Pass the frame to 
radio interface 
protocols 



In the table above if any of the sublows have the 'Delivery of erroneous SDUs' set to 'Yes' or 'No', and the FQC or 
CRC check indicates that the lu UP is bad, then the lu UP frame should be dropped. 

NOTE: The case where SRNC receives a frame with the FQC set to to "bad radio" (respectively: "bad"), 

corresponds to a TrFO (respectively: TFO) case. The frame is then trashed by the receiving RNC since 
there is currently no means to pass down to the UE the frame quality indicator. 



£75/ 



3GPP TS 25.415 version 3.4.0 Release 1999 



18 



ETSI TS 125 415 V3.4.0 (2000-09) 



6.5 Elementary procedures 
6.5.1 Transfer of User Data procedure 



6.5.1.1 



Successful operation 



The purpose of the transfer of user data procedure is to transfer lu UP frames between the two lu UP protocol layers at 
both ends of the lu interface. Since an lu UP instance is associated to a RAB and a RAB only, the user data being 
transferred only relate to the associated RAB. 

The procedure is controlled at both ends of the lu UP instance i.e. SRNC and the CN. 

The transfer of user data procedure is invoked whenever user data for that particular RAB needs to be sent across the lu 
interface. 

The procedure is invoked by the lu UP upper layers upon reception of the upper layer PDU and associated control 
information: RFCI. 

In SRNC, the upper layers may deliver a frame quality classification information together with the RFCI. 

The NAS Data streams functions makes the padding of the payload (if needed) so that the lu UP frame payload will be 
an integer number of octets. Then the NAS Data streams functions perform, if needed, CRC calculation of the lu frame 
payload and passes the lu UP frame payload down to the frame handler together with the RFCI. 

The frame handler function retrieves the frame number from its internal memory, formats the frame header and frame 
payload into the appropriate PDU Type and sends the lu UP frame PDU to the lower layers for transfer across the lu 
interface. 

For RABs with the traffic class conversational or streaming the frame number shall be based on time (stepped at each 
ITI). For RABs with another type of traffic class the frame numbering shall be based on sent lu UP PDU (stepped at 
each sent lu UP PDU). See description of Frame number. 

Upon reception of a user data frame, the lu UP protocol layer checks the consistency of the lu UP frame as follows: 

the Frame handler checks the consistency of the frame header. If correct, the frame handler stores the frame 
number and passes the lu UP frame payload and associated CRC, if any to the NAS Data Streams functions. The 
received RFCI is passed to the Procedure Control Function; 

the NAS Data Streams functions check the payload CRC, if any. If the RFCI is correct (i.e. RFCI is used at 
Initialisation) and matches the lu UP frame payload (i.e. frame payload is not too short for the RFCI) as 
indicated by the Procedure Control functions, the NAS Data Streams removes the padding bits and the spare 
extension field when present from the lu UP frame payload based on the RFCI information. Then the NAS Data 
Streams forwards to the upper layers the RFCI and the payload. 



RNC/ 

CN Transfer of User Data 
(RFCI, payload) 



CN/ 



RNC 



Figure 7: Successful Transfers of User Data 
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6.5.1.2 



Unsuccessful operation 



If the lu UP frame carrying the user data is incorrectly formatted or cannot be correctly treated by the receiving lu UP 
protocol layer, the lu UP protocol layer shall either discard the frame or pass it to the upper layers with a frame 
classification indicating a corrupted frame. This decision is based on configuration data of the lu UP instance for that 
particular RAB (i.e. if the RAB requests delivery of corrupted frame). 

If the lu UP protocol layer detects a frame loss because of a gap in the received frame number sequence while the frame 
number does not relate to time (see subclause Frame Number), the receiving lu UP protocol layer shall report this to the 
procedure control function. 



RNC/ 
CN 



Transfer of User Data 
(RFCI, payload) 



CN/ 
RNC 




Figure 8: Unsuccessful Transfers of User Data: 1) Corrupted Frame, 2) Detection of Frame loss 

6.5.2 Initialisation procedure 



6.5.2.1 



Successful operation 



This procedure is mandatory for RABs using the support mode for predefined SDU size. The purpose of the 
initialisation procedure is to configure both termination points of the lu UP with the RFCIs and associated RAB Sub 
Flows SDU sizes necessary during the transfer of user data phase. Additional parameters may also be passed, as the 
Inter PDU Timing Interval (IPTI) information. 

The initialisation procedure is always controlled by the entity in charge of establishing the Radio Network Layer User 
Plane i.e. SRNC. 

The initialisation procedure is invoked whenever indicated by the lu UP Procedure Control function e.g. as a result of a 
relocation of SRNS or at RAB establishment over lu. 

When this procedure is invoked all other lu UP procedures are suspended until termination of the initialisation 
procedure. 

The RNC indicates the lu UP Mode version it uses for the initialisation as well as the lu UP Mode versions it supports 
for the related RAB. The sender should use the lowest version for the initialisation that has enough information to 
initialise the highest proposed protocol version. 

The SRNC allocates a RAB sub-Flow Combination indicator (RFCI) to each RAB sub-Flow Combination it initialises. 
The association of indicators to RAB Flow Combinations is valid in the lu UP until a new initialisation procedure is 
performed or the connection is terminated. 

The procedure control function may also generate additional lu UP protocol parameters necessary for the RAB service 
to operate properly over lu. 

To each RAB sub-Flow combination indicator is associated the size of each RAB sub-Flow SDU of that combination. 
The list of RAB sub-Flow Combination Indicators and their respective SDU sizes constitutes the RAB sub-Flow 
Combination set passed over the lu UP in the initialisation frame i.e. into an appropriate lu UP PDU Type. 

The first RAB sub-Flow Combination proposed in the list of RAB sub-Flow Combination indicates the initial RAB sub- 
Flow Combination i.e. the first RAB sub-Flow Combination to be used when starting the communication phase i.e. the 
transfer of user data procedure. 

The complete set of information is framed by the lu UP Frame Handler function and transferred in an lu UP 
initialisation frame. If needed, the initialisation frame CRC is calculated and set accordingly in the respective frame 
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field. 

A supervision timer T init is started after sending the lu UP initialisation frame. This timer supervises the reception of 
the initialisation acknowledgement frame. 

Upon reception of a frame indicating that an initialisation control procedure is active in the peer lu UP entity, the lu UP 
protocol layer forwards to the upper layers the RAB sub-Flow Combination set to be used by the Control procedure 
function. It also stores the RAB sub-Flow Combination set in order to control during the transfer of user data, that the lu 
UP payload is correctly formatted (e.g. RFCI matches the expected lu UP frame payload total length). The entity 
receiving the initialisation message shall choose a version that it supports and for which it has enough initialisation 
information. This entity could be in the CN, or in a RNC, e.g. in case of TrFO. 

If the initialisation frame is correctly formatted and treated by the receiving lu UP protocol layer, this latter sends an 
initialisation acknowledgement frame using the version of the lu UP Mode that is chosen. 

Upon reception of an initialisation acknowledgement frame, the lu UP protocol layer in the SRNC stops the supervision 
timer Tinit- 

If the initialisation procedure requires that several frames are to be sent, each frame shall be acknowledged individually. 

If several initialisation frames are used for the initialisation procedure, the next frame shall wait for the 
acknowledgement of the previous frame to be received before sending. The supervision timer is used individually for 
each frame in a chain. 

The frame number is always set to zero for the first frame in a chain and it shall be incremented in the sending direction 
for each sent frame. The acknowledgement or negative acknowledgement carries the frame number of the frame being 
acknowledged. 

Upon reception of an initialisation negative acknowledgement frame or at timer T init expiry, the lu UP protocol layer 
in the SRNC shall reset and restart the T init supervision timer and repeat an initialisation frame. The repetition can be 
performed N init times, N init being chosen by the operator (default N init = 3). 

Consequently, when in the communication phase (as indicated by internal functions in the Radio Network layer), the 
frame transmission starts in downlink in the initial RFCI. 

In the case where an SRNC receives an lu frame indicating that an initialisation procedure is active at the other end of 
the lu UP, RFCI is applied as follows: 

for the sending frame, i.e. UL direction, RNC uses the RAB sub-Flows Combination set indicated in 
Initialisation phase of the peer TFO or TrFO partner; 

for the receiving frame, i.e. DL direction, RNC uses the RAB sub-Flows Combination set as sent in its own 
initialisation frame. 



RNC 



CN/ 
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Initialisation ,, 

((RFCI, SDU sizes[, IPTIs^']) !)"^''^'^ 



-► 



Initialisation ACK 



Transfer Of User Data 



* it can repeated n times 
"' optional 

Figure 9: Successful Initialisation of lu UP for m RFCIs 

6.5.2.2 Unsuccessful operation 

If the initialisation frame is incorrectly formatted and cannot be correctly treated by the receiving lu UP protocol layer, 
this latter sends an initialisation negative acknowledgement frame. 

If the receiver does not support the lu UP Mode version for the initialisation procedure, it shall send a negative 
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acknowledgement using the highest version it supports among the versions proposed by the sender. If none of the 
proposed versions are supported, the receiver shall respond a negative acknowledgement using the highest version it 
supports. 

If after N inu repetition, the initialisation procedure is unsuccessfully terminated (because of N init negative 
acknowledgement or timer T init expires), the lu UP protocol layers (sending and receiving) take appropriate local 
actions. 
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* after n repetitions 
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Figure 10: Unsuccessful initialisation of lu UP: 1) N init negative acknowledgement 

or 2) N INIT timer expires 

NOTE: The case where an SRNC receives an lu frame indicating that an initialisation procedure is active at the 
other end of the lu UP could be related to a TFO or TrFO negotiation. How TFO or TrFO protocol and 
codec negotiation is performed is FFS. 

6.5.3 lu Rate Control procedure 
6.5.3.1 Successful operation 

The purpose of the rate control procedure is to signal to the peer lu UP protocol layer the permitted rate(s) over lu in the 
reverse direction of the sent rate control frame. 

The rate control procedure over lu UP is normally controlled by the entity controlling the rate control over UTRAN 
i.e. SRNC. In some cases, as TrFO and TFO, it is also controlled by the remote partner at the other end of the lu UP. 

The lu rate control procedure is invoked whenever the SRNC decides that the set of downlink permitted rates over lu 
shall be modified. This set can be made of only one permitted rate among the rates that are permitted for rate control or 
several rates among the rates that can be rate controlled by the SRNC. 

The rates that can be controlled by the SRNC are the rates that are above the guaranteed bitrate (indicated to the lu UP 
at establishment) Rates below the guaranteed bitrate, e.g. SID frames, cannot be controlled by the RNC. 

The procedure can be signalled at any time when transfer of user data is not suspended by another control procedure. 

The Procedure control function upon request of upper layer prepares the Rate control frame payload contairung the 
permitted rates of the reverse direction of the rate control frame. The permitted rate is given as RFCI indicators. 

The frame handler function calculates the frame CRC, formats the frame header into the appropriate PDU Type and 
sends the lu UP frame PDU to the lower layers for transfer across the lu interface. 

Upon reception of a rate control frame, the lu UP protocol layer checks the consistency of the lu UP frame as follows: 

the Frame handler checks the consistency of the frame header and associated CRC. If correct, the frame handler 
passes procedure control part to the procedure control functions; 

the procedure control functions check that the new permitted rate(s) are consistent with the RFCI set received at 
initialisation. They also verify that non-rate controllable rates are still permitted. If the whole rate control 
information is correct, the procedure control functions passes the rate control information to the NAS Data 
Streams specific functions; 

the NAS data streams specific functions forward to the upper layers the rate control information in a lu-UP- 
Status indication primitive. 



£75/ 



3GPP TS 25.415 version 3.4.0 Release 1999 



22 



ETSI TS 125 415 V3.4.0 (2000-09) 



RNC 



Rate Control 
(RFCI indicators) 



CN/ 

other 



Figure 1 1 : Successful Rate Control sent from SRNC 
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Figure 12: Successful Rate Control sent from CN 



6.5.3.2 



Unsuccessful operation 



If the lu UP in the SRNC detects that the rate control command has not been correctly interpreted or received (e.g. the 
rate is outside the set of permitted rates in the reverse direction of the rate control frame), the lu UP shall retrigger a rate 
control procedure. If after N rc repetitions, the error situation persists, the lu UP protocol layers (sending and receiving) 
take the appropriate local actions. 

If the lu UP protocol layer receives a rate control frame that is badly formatted or corrupted, it shall ignore the rate 
control frame. 
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Figure 13: Unsuccessful Transfer of rate control from RNC: 1) Frame loss 2) Corrupted Frame 
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Figure 14: Unsuccessful Transfer of rate control from CN: 1) Frame loss 2) Corrupted Frame 
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6.5.4 Time Alignment procedure 



6.5.4.1 



Successful operation 



The purpose of the time aUgnment procedure is to minimise the buffer delay in RNC by controlhng the transmission 
timing in the peer lu UP protocol layer entity. 

The time alignment procedure over lu UP is controlled by SRNC. 

The time alignment procedure is invoked whenever the SRNC detects the reception of lu UP PDU at an inappropriate 
timing that leads to an unnecessary buffer delay. The actual detection of the trigger in SRNC is an internal SRNC matter 
and is out of the scope of the present document. 

The lu UP protocol layer entity in SRNC indicates the peer entity the necessary amount of the delay or advance 
adjustment in the number of 500 |js steps. 

A supervision timer Txa is started after sending the lu UP time alignment frame. This timer supervises the reception of 
the time alignment acknowledgement frame. 

The requested lu UP protocol layer entity in the peer node adjusts the transmission timing by the amount as indicated by 
SRNC. 

If the time alignment frame is correctly formatted and treated by the receiving lu UP protocol layer and the time 
alignment is treated correctly by the upper layers, this latter sends an time alignment acknowledgement frame. 

Upon reception of a time alignment acknowledgement frame, the lu UP protocol layer in the SRNC stops the 
supervision timer Tja- 

The procedure can be signalled at any time when transfer of user data is not suspended by another control procedure. 
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Figure 15a: Successful Time Alignment 
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6.5.4.2 



Unsuccessful operation 



If the Time Alignment could not be handled by the peer side, the peer side should send a NACK with a corresponding 
cause. When the lu UP in the SRNC receives a NACK with cause "Time Alignment not supported", then the SRNC 
shall not send additional Time Alignment frames for that RAB (unless the lu UP conditions change for that RAB). The 
cause value "Requested Time Alignment not possible" is used to indicate that the requested time alignment was not 
possible at that moment. At a later moment the SRNC may initiate a new Time Alignment command when needed. 

If the lu UP in the SRNC detects that the time alignment command has not been correctly interpreted or received, 
i.e NACK received or timer expkes, and the time alignment need still persists, the lu UP should retrigger a time 
alignment procedure. If after N xa repetitions, the error situation persists, the lu UP protocol layers take appropriate 
local actions. 

Upon reception of a time alignment negative acknowledgement frame, the lu UP protocol layer in the SRNC stops the 
supervision timer Tja- 

If the lu UP protocol layer in RNC receives a Time Alignment frame (e.g. at TrFO case) a NACK shall be sent with the 
cause value "Time Alignment not supported". 
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Figure 16a: Unsuccessful Time Alignment: 1) N ta negative acknowledgements 

or 2) N TA timer expiries 

6.5.5 Handling of Error Event procedure 



6.5.5.1 



Successful operation 



The purpose of the Error event procedure handles the error reporting. Over the lu UP protocol the error reports are made 
with Error event frames. The Error event procedure in the lu UP can be triggered by: 

an error detected by the lu UP functions (by receiving an erroneous frame or by receiving a frame with unknown 
or unexpected data). In this case an lu UP- Status Indication may be used to inform the upper layers; 

a request by the upper layers. 

When an Error event is reported by an Error event frame the following information shall be included: 

a cause value; 

error distance (=0 if lu UP function detected, =1 if requested by upper layers). 

Upon reception of an Error report frame the lu UP functions should take appropriate local actions based on the cause 
value. This may include to report the error to the upper layers with an lu UP status indication. 
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Figure 15b: Successful Error event 



6.5.5.2 



Unsuccessful operation 



If the error event frame is incorrectly formatted and cannot be correctly treated by the receiving lu UP protocol layer 
appropriate local actions are taken (e.g. upper layers are informed). An error in an Error event frame should not 
generate the sending of an new Error event frame. 
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Figure 16b: Unsuccessful Transfer of Error event frame: 1) Frame loss 2) Corrupted Frame 

6.5.6 Frame Quality Classification 

The Frame QuaUty Classification procedure uses the services of the Transfer of User Data procedure to exchange across 
the lu UP interface the Frame Quality Classification information. 

rRNO 



CN Transfer of User Data 
(FQC, RFCI, payload) 

Transfer of User Data 
(FQC, RFCI, payload) 



CN/ 
RNC 



Figure 17: Successful Transfers of User Data with FQC information 

6.6 Elements for lu UP communication in Support mode 
6.6.1 General 

In the present document the structure of frames will be specified by using figures similar to figure 18. 
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1 


Octet 1 


Header 
part 


Field 3 


Field 4 
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Octet 2 
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Field 4 continue 
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Field 6 
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Octet 4 
Octet 5 


Payload 
part 


Field 6 continue 


Padding 


Spare extension 


0-m 





Figure 18: Example frame format 

Unless otherwise indicated, fields which consist of multiple bits within a octet will have the more significant bit located 
at the higher bit position (indicated above frame in figure 18). In addition, if a field spans several octets, more 
significant bits will be located in lower numbered octets (right of frame in figure 18). 

On the lu interface, the frame will be transmitted starting from the lowest numbered octet. Within each octet, the bits 
are sent according decreasing bit position (bit position 7 first). 

Spare bits should be set to by the sender and should not be checked by the receiver. 

The header part of the frame is always an integer number of octets. The payload part is octet rounded (by adding 
'Padding' when needed). 

The receiver should be able to remove an additional spare extension field that may be present at the end of a frame. See 
description of Spare extension field. 

6.6.2 Frame Format for predefined size SDUs 



6.6.2.1 



PDU Type 



PDU Type is defined to transfer user data over the lu UP in support mode for pre-defined SDU sizes. Error detection 
scheme is provided over the lu UP for the payload part. 

The following shows the lu frame structure for PDU type of the lu UP protocol at the SAP towards the transport 
layers (TNL-SAP). 
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Bits 


-z. 
o 3 




7 


6 


5 


4 


3 


2 


1 









PDU Type (=0) 


Frame Number 


1 


Frame 
Control 
Part 


FQC 


RFC! 


1 


Header CRC 


Payload CRC 


2 


Frame 
Check 
Sum Part 


Payload CRC 


Payload Fields 


0-n 


Frame 

Payload 

part 


Payload Fields 


Padding 


Spare extension 


0-4 



Figure 19: lu UP PDU Type Format 

The lu UP PDU Type is made of three parts: 

1) lu UP Frame Control part (fixed size); 

2) lu UP Frame Check Sum part (fixed size); 

3) lu UP Frame Payload part (pre-defined SDU sizes rounded up to octets [Note: this does not consider the usage of 
spare extension field]). 

The lu UP Frame Control Part and the lu UP Frame Check Sum constitute the lu UP PDU Type Frame Header. 

6.6.2.2 PDU Type 1 

PDU Type 1 is defined to transfer user data over the lu UP in support mode for pre-defined SDU sizes when no payload 
error detection scheme is necessary over lu UP (i.e. no payload CRC). 

The following shows the lu frame structure for PDU type 1 of the lu UP protocol at the SAP towards the transport 
layers (TNL-SAP). 
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Bits 


-z. 
o 3 




7 


6 


5 


4 


3 


2 


1 









PDUType(=1) 


Frame Number 


1 


Frame 
Control 
Part 


FQC 


RFCI 


1 


Header CRC 


Spare 


1 


Frame 
Check 
Sum Part 


Payload Fields 


0-n 


Frame 

Payload 

part 


Payload Fields 


Padding 


Spare extension 


0-4 



Figure 20: lu UP PDU Type 1 Format 

The lu UP PDU Type 1 is made of three parts: 

1) lu UP Frame Control part (fixed size); 

2) lu UP Frame Check Sum part (fixed size); 

3) lu UP Frame Payload part (pre-defmed SDU sizes, rounded up to octets [Note: this does not consider the usage 
of spare extension field]). 

The lu UP Frame Control Part and the lu UP Frame Check Sum constitute the lu UP PDU Type 1 Frame Header. 



6.6.2.3 



PDU Type 14 



6.6.2.3.1 



General 



PDU Type 14 is defined to perform control procedures over the lu UP in support mode for pre-defined SDU sizes. The 
control procedure is identified by the procedure indicator. The Frame Payload contains the data information related to 
the control procedure. 

Figure 21 below shows the lu frame structure for PDU Type 14 of the lu UP protocol at the SAP towards the transport 
layers (TNL-SAP). 
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Bits 


-z. 
o 3 
CO -> 

o 




7 


6 


5 


4 


3 


2 


1 







PDUType{=14) 


Ack/Nack (=0, 
i.e. procedure) 


PDUType 14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator 


1 


Header CRC 


Payload CRC 


1 


Frame 
Checksu 
m Part 


Payload CRC 


1 


Reserved for procedure data 


0-n 


Frame 

payload 

part 


Spare extension 


0-32 



Figure 21 : lu UP PDU Type 14 Format for procedure sending 

The lu UP PDU Type 14 is made of three parts: 

1) lu UP Frame Control part (fixed size); 

2) lu UP Frame Check Sum part (fixed size); 

3) lu UP Frame Payload part (variable length, rounded up to octet). 

The lu UP Frame Control Part and the lu UP Frame Check Sum constitute the lu UP PDU Type 14 Frame Header. 

6.6.2.3.2 Positive Acknowledgement 

When the PDU Type 14 is used to positively acknowledge a control procedure, the PDU Type 14 frame takes the 
following structure at the TNL-SAP. 
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Bits 


-z. 
o 3 
CO -> 

o 




7 


6 


5 


4 


3 


2 


1 







PDUType{=14) 


Ack/Nack(=1, 
i.e. Ack) 


PDUType 14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator 

(indicating the procedure being 
positively acknowledged) 


1 


Header CRC 


Spare 


1 


Frame 
Checksu 
m Part 


Spare 


1 


Spare extension 


0-32 


Frame 

Payload 

part 



Figure 22: lu UP PDU Type 14 Format for positive acknowledgement 

The lu UP Frame Control Part and the lu UP Frame Check Sum constitute the lu UP PDU Type 14 Frame Header for 
positive acknowledgement. 



6.6.2.3.3 



Negative Acknowledgement 



When the PDU Type 14 is used to negatively acknowledge a control procedure, the PDU Type 14 frame takes the 
following structure at the TNL-SAP. 



Bits 


"1 

CO -> 

o 




7 


6 


5 


4 


3 


2 


1 







PDU Type (=14) 


Ack/Nack (=2, 
i.e. Nack) 


PDUType 14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator 

(indicating the procedure being 
negatively acknowledged) 


1 


Header CRC 


Spare 


1 


Frame 
Checksu 
m Part 


Spare 


1 


Error Cause value 


Spare 


1 


Frame 

payload 

part 


Spare extension 


0-32 



Figure 23: lu UP PDU Type 14 Format for negative acknowledgement 

The lu UP Frame Control Part and the lu UP Frame Check Sum constitute the lu UP PDU Type 14 Frame Header for 
negative acknowledgement. 
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6.6.2.3.4 



Procedures Coding 



6.6.2.3.4.1 Initialisation 

Figure 24 specifies how the initialisation procedure frame is coded. 



Bits 


-z. 
o 3 

en -> 
O 




7 


6 


5 


4 


3 


2 


1 







PDUType(=14) 


Ack/Nack (=0. 
I.e. Procedure) 


PDU Type 14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator (=0) 


1 


Header CRC 


Payload CRC 


2 


Frame 

Checksum 

part 


Payload CRC 


Spare 


Tl 


Number of subflows per 
RFCI (N) 


Chain 
Ind 


1 


Frame 

payload 

part 


LRI 


LI 


I^RFCI 


1 


Length of subflow 1 


1 or 2 
(dep. LI) 


Length of subflow 2 to N 


(N-I)x(l 
or 2) 


LRI 


LI 


2"'^ RFCI 


1 


Length of subflow 1 


1 or 2 
(dep. LI) 


Length of subflow 2 to N 


(N-I)x(l 
or 2) 






IPTIof f'RFCI 


IPTI of 2"^^ RFCI 


or N/2 


IPTI of 3'" RFCI 




lu UP Mode Versions supported (bitmap) 


2 


Data PDU type 


Spare 


1 


Spare extension 


0-32 



Figure 24: lu UP PDU Type 14 used for Initialisation 



6.6.2.3.4.2 Rate Control 

Figure 25 specifies how the rate control procedure frame is coded. 
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Bits 


-z. 
o 3 
CO -> 

o 




7 


6 


5 


4 


3 


2 


1 









PDUType{=14) 


Ack/Nack (=0, 
i.e. Procedure) 


PDUType 14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator (=1) 


1 


Header CRC 


Payload CRC 


1 


Frame 
Checksu 

m Part 


Payload CRC 


1 




Spare 


Number of RFCIs(N) 


1 


Frame 

payload 

part 


RFCIO 
Ind. 


RFCI 1 
Ind 




RFCI 
N-1 
Ind 


Padding 


0-n 


Spare extension 


0-32 





Figure 25: lu UP PDU Type 14 Format used for Rate Control 



6.6.2.3.4.3 Time Alignment 

Figure 26 specifies how the time alignment procedure is coded. 



Bits 


"1 
o 




7 


6 


5 


4 


3 


2 


1 







PDU Type (=14) 


Ack/Nack(=0) 


PDU Type 14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator (=2) 


1 


Header CRC 


Payload CRC 


1 

1 


Frame 
Checksu 
m Part 


Payload CRC 


Time alignment 


1 


Frame 

payload 

part 


Spare extension 


0-32 



Figure 26: lu UP PDU Type 14 Format used for Time Alignment 



6.6.2.3.4.4 Error Event 

Figure 27 specifies how the Error Event procedure is coded. 
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Bits 


-z. 
o 3 
CO -> 

o 




7 


6 


5 


4 


3 


2 


1 







PDUType(=14) 


Ack/Nack(=0) 


PDUType 14 
Frame Number 


1 


Frame 
Control 
Part 


lu UP Mode version 


Procedure Indicator (=3) 


1 


Header CRC 


Payload CRC 


1 
1 


Frame 
Checksu 
m Part 


Payload CRC 


Error distance 


Error Cause value 


1 


Frame 

payload 

part 


Spare extension 


0-32 



Figure 27: lu UP PDU Type 14 Format used for Error Event 



6.6.3 Coding of information elements in frames 



6.6.3.1 



PDU Type 



Description: The PDU type indicates the structure of the lu UP frame. The field takes the value of the PDU Type it 
identifies: i.e. for PDU Type 0. The PDU type is in bit 4 to bit 7 in the first octet of the frame. PDU type is used in all 
frames in support mode for predefined SDU sizes version 1 . 

Value range: {0-1 and 14 in use, 2-13: reserved for future PDU types, 15=reserved for future PDU type extensions} 

Field length: 4 bits 

6.6.3.2 Ack/Nack 

Description: The Ack/Nack field tells if the frame is: 

a control procedure frame; 

a positive acknowledgement (ACK) of a control procedure frame; 

a negative acknowledgement (NACK) of a control procedure frame. 
Value range: {O=control procedure frame, 1=ACK, 2=NACK, 3=reserved} 
Field length: 2 bits 



6.6.3.3 



Frame Number 



Description: The lu UP frame numbering is handled by a Frame Number. The frame numbering can be based on either 
time or sent lu UP PDU. In case the frame numbering is based on time the purpose of the frame number is to be of help 
in handling the Time Alignment functionality. When the frame number is based on time, the Frame number is 
incremented by one (modulo 16) at each new ITI. In case the Frame number relates to sent lu UP PDU the purpose of 
the Frame Number is to provide the receiving entity with a mechanism to keep track of lost lu UP frames. When the 
frame number is based on sent lu UP PDU, the Frame number is incremented by one (modulo 16) for each sent lu UP 
PDU. For a given user data connection, there is no relations between the frame numbers of frames sent in the downlink 
direction and the frame numbers of frames sent in the uplink direction. 

Value range: {0-15}. 
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Field length: 4 bits. 

6.6.3.4 PDU Type 14 Frame Number 

Description: The lu UP frame numbering is handled by a Frame Number. The purpose of the PDU Type 14 Frame 
Number is to provide the receiving entity with a mechanism to keep track of lost lu UP framesTt is also used to relate 
the acknowledgment frame to the frame being acknowledged i.e. the same PDU Type 14 Frame Number is used in the 
acknowledgement frame as the one used in the frame being acknowledged. 

Value range: {0-3}. 

Field length: 2 bits. 

6.6.3.5 Frame Quality Classification (FQC) 

Description: Frame Quality Classification is used to classify the lu UP frames depending on whether errors have 
occurred in the frame or not. Frame Quality Classification is dependent on the RAB attribute 'Delivery of erroneous 
SDUs'. 

Value range: {0=frame good, l=frame bad, 2=Frame bad due to radio, 3=spare}. 

Field length: 2 bits. 

6.6.3.6 RAB sub-Flow Combination Indicator (RFCI) 

Description: The RPCI identifies the structure of the payload. This can be used to specify the sizes of the subflows. 
Value range: {0-62, 63=RFCI not apphcable}. 
Field length: 6 bits. 

6.6.3.7 Procedure Indicator 

Description: The Procedure Indicator identifies the control procedure in the current frame. 
Value range: {O=initialization, l=rate control, 2=time alignment, 3=error event, 4-15=reserved}. 
Field length: 4 bits. 

6.6.3.8 Header CRC 

Description: This field contains the CRC of all fields in Frame Control Part. The CRC is a 6-bit checksum based on the 
generator polynom G(D) = D''h-D^h-D^h-D^h-D'h-1, see subclause 6.7.7. With this CRC all error bursts shorter than 7 bits 
are detected, as well as all odd number of bits faulty (and two-bit faults) when the protected area is shorter than 24 bits, 
(max 3 octets). 

Field length: 6 bits. 

6.6.3.9 Payload CRC 

Description: This field contains the CRC of all the fields (including Padding and possible Spare extension) of the 
Frame Payload Part. The CRC is a 10 bit checksum based on the generator polynom G(D) = D'^h- DVD^h-D*h-D'h-1, see 
subclause 6.7.7. With this CRC all error bursts shorter than 1 1 bits are detected, as well as all odd number of bits faulty 
(and two-bit faults) when the protected area is shorter than 500 bits (max 62 octets). 

Field length: 10 bits. 
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6.6.3.10 Chain Indicator 

Description: Chain indicator is used to indicate whether the control procedure frame is the last frame related to the 
control procedure. 

Value range: {0=this frame is the last frame for the procedure, l=additional frames will be sent for the procedure}. 

Field length: 1 bit. 

6.6.3.11 Number of Subflows per RFC! 

Description: Number of Subflows per RFCI field indicates the number of subflows the RAB is made of It is used to 
decode the SDU size information data lengths. All RFCs consist of the same number of subflows within a specific 
RAB. 

Value range: {0=reserved, 1-7}. 

Field length: 3 bits. 

6.6.3.12 Length Indicator (LI) 

Description: Length Indicator, indicates if 1 or 2 octets is used for the RAB subflow size information. 
Value range: {O=one octet used, l=two octets used}. 
Field length: 1 bit. 

6.6.3.13 Number of RFCI Indicators 

Description: Number of RFCI indicators indicates the number of RFCI indicators present in the control procedure 
frame. 

Value range: {0-63}. 

Field length: 6 bits. 

6.6.3.14 RFCI n Indicator 

Description: RFCI n Indicator points to an RFCI number e.g. RFCI Indicator points to RFCI 0, RFCI 1 Indicator 
points to RFCI 1 , etc . . . 

Value range: {0=RFCI allowed, 1=RFCI barred}. 

Field length: 1 bit. 

6.6.3.15 Error distance 

Description: Indicates if the error occurred at the error reporting entity (=0) or in a more distant entity. The error 
distance is incremented by one (or kept at its maximum value) when an error report is forwarded. 

0: Reporting local error 
1 : First forwarding of error event report 
2: Second forwarding of error event report 
3: Reserved for future use 

Value range: {0: Reporting local error, 1: First forwarding of error event report. 2: Second forwarding of error event, 3: 
Reserved for future use } . 

Field length: 2 bit. 
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6.6.3.1 6 Error Cause value 

Description: Cause value is used to indicate what kind of error caused the error. Error cause value is used in NACK 
and Error Event frames. 

0: CRC error of frame header 

1 : CRC error of frame payload 

2: Unexpected frame number 

3: Frame loss 

4: PDU type unknown 

5: Unknown procedure 

6: Unknown reserved value 

7: Unknown field 

8: Frame too short 

9: Missing fields 

10-15: spare 

16: Unexpected PDU type 

18: Unexpected procedure 

19: Unexpected RFCI 

20: Unexpected value 

21^1: spare 

42: Initialisation failure 

43: Initialisation failure (timer expiry) 

44: Initialisation failure (repeated NACK) 

45: Rate control failure 

46: Error event failure 

47: Time Alignment not supported 

48: Requested Time Alignment not possible 

49: lu UP Mode version not supported 

50-63: spare 

Value range: {0-15 Used for syntactical protocol errors, 16^1 Used for semantical protocol errors, 42-63 Used for 
other errors } . 

Field length: 6 bit. 

6.6.3.17 Padding 

Description: This field is an additional field used to make the frame payload part an integer number of octets when 
needed. Padding is set to by the sender and is not interpreted by the receiver. 

Value range: {0-127}. 

Field length: 0-7 bits. 

6.6.3.18 Time alignment 

Description: Time alignment indicates the amount the sending time should be advanced or delayed. 

0: Reserved 

1: Delay l*500)is 

80: Delay 80*500)is 
81-127 Reserved 
128: Reserved 
129: Advance l*500)is 

208: Advance 80*500)is 
209-255 Reserved 

Value range: {0: Reserved, 1-80: used for delay, 81-128: Reserved, 129-208 used for advance, 209-255: Reserved}. 

Field length: 8 bit. 
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6.6.3.19 Spare 

Description: The spare field is set to by the sender and should not be interpreted by the receiver. 
Value range: (0-2"-l). 
Field Length: n bits. 

6.6.3.20 Spare extension 

Description: The spare extension field shall not be sent. The receiver should be capable of receiving a spare extension. 
The spare extension should not be interpreted by the receiver. This since in later versions of the present document 
additional new fields might be added in place of the spare extension. The spare extension can be an integer number of 
octets carrying new fields or additional information; the maximum length of the spare extension field (m) depends on 
the PDU type. 

Value range: 0-2'"***-l. 

Field Length: 0-m octets. For PDU Types in the set {0,1 }, m=4. For PDU Types in the set { 14}, m=32. 

6.6.3.21 LRI, Last RFCI Indicator 

Description: The Last RFCI Indicator is used to indicate which is the last RFCI in the current Initialisation frame. This 
makes it possible for a receiver to detect a spare extension field. 

Value range: (0: Not last RFCI, 1: Last RFCI in current frame). 

Field Length: 1 bit. 

6.6.3.22 Length of subflow 

Description: This field indicates the length of the corresponding subflow as number of bits per SDU. 
Value range: (0-255 if LI=0, 0-65535 if LI=1). 
Field Length: 8 or 16 bits (depending on LI). 

6.6.3.23 Tl 

Description: This field indicates if Timing Information is included in the Initialisation frame. 
Value range: {0: IPTIs not present, 1: IPTIs present in frame}. 
Field length: 1 bit. 

6.6.3.24 IPTI of n'^ RFCI 

Description: This field indicates the IPTI value in number of ITIs for the corresponding RFCI (in the same order as the 
RFCIs occur in the Initialisation frame). 

Value range: {0-15}. 

Field length: 4 bits. 

6.6.3.25 lu UP Mode versions supported 

Description: This field indicates the lu UP Mode Versions supported by the RNC for the related RAB. Up to 16 lu UP 
Mode versions can be simultaneously available. 

Value range: 

Each bit, in the two octet field, indicates a lu UP Protocol version: (First octet, bit 7) indicates version 16, (Second 
octet, bit 0) indicates version 1 . 
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Bit = means "Version not supported" 
Bit = 1 means "Version supported" 
Field length: 2 octets 



6.6.3.26 



lu UP Mode Version 



Description: This field indicates the lu UP Mode version. Up to 16 lu UP Mode Versions can be simultaneously 
available. 

Value range: { 1-16} The binary coded value is the version number minus 1 (e.g. version 1 is coded '0000', ..., version 
16 is coded '1111'). 

Field length: 4 bits 

6.6.3.27 Payload fields 

Description: This field contains the Subflow SDUs, starting with the Subflow 1 SDU. The MSB of the Subflow 1 SDU 
is placed in bit 7 of the first octet (see example in Figure 27a below). 

Value range: {any value}. 

Field length: Sum of the lengths of the included Subflow SDUs. 



Bits 


g| 

Q CD 


7 


6 


5 


4 


3 


2 


1 





Subflow 1 SDU 


1 


Subflow 1 SDU cont. 


Subflow 2 SDU 


1 


Subflow 2 SDU cont. 


Padding 

(Not part of 

'Payload fields') 


1 



Figure 27a: Example of 'Payload fields' with two Subflow SDUs 

6.6.3.28 Data PDU type 

Description: This field indicates the PDU type that shall be used (in both directions) for transferring user data. The 
selection of the PDU type is made by UTRAN based on the reliability attributes. If the reliability attribute 'Delivery of 
erroneous SDUs' equals 'no-error-detection-consideration' for all subflows then PDU type 1 shall be used. 

Value range: {0: PDU type 0, 1: PDU type 1, 2-15: Reserved for future use}. 

Field length: 4 bits. 

6.6.4 Timers 



This Timer is used to supervise the reception of the initialisation acknowledgement frame from the peer lu UP instance. 
This Timer is set by O&M. 



This Timer is used to supervise the reception of the time alignment acknowledgement frame from the peer lu UP 
instance. This Timer is set by O&M. 
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6.6.5 Maximum values of repetition counters 

NiNIT 

Maximum number of repetitions of an Initialisation frame due to failure at the Initialisation procedure. 

Nrc 

Maximum number of repetitions of a Rate Control frame due to failure at the Rate Control procedure. 

Nta 

Maximum number of repetitions of a Time Alignment frame due to failure at the Time Alignment procedure. 

6.7 Handling of unknown, unforeseen and erroneous protocol 
data 

6.7.1 General 

Error handling in lu UP protocol is applicable only for lu UP in Support mode. 

The Error Event procedure is the procedure handling error reporting. The Error event procedure in the lu UP can be 
triggered by: 

an error detected by the lu UP functions (by receiving an erroneous frame or by receiving a frame with unknown 
or unexpected data); 

a request by the upper layers; 

an Error event frame over the lu UP protocol. 

The error can be reported either by: 

an Error event frame over the lu UP protocol; 

an lu UP Status Indication to upper layers (e.g. to be used by O&M). 

When an Error event is reported, either by an lu-UP-Status-Indication, or by an Error event frame the following 
information shall be included: 

type of the error (syntactical error, semantical error or other error); 

error distance, i.e. information where the error occurred. 

6.7.2 Error detected by lu UP functions 

When an error is detected within the lu UP functions (by receiving a frame containing erroneous, unknown or 
unexpected data) one of the following actions is taken depending on the type of the error: 

1. error indicated to upper layers by sending a lu-UP-Status-Indication primitive; 

2. error event frame sent; 

3. error event frame sent and error indicated to upper layers by sending a lu-UP-Status-Indication primitive; 

4. no action. 



6.7.3 Request by upper layers 



When the lU UP receives an lu-UP-Status-Request indicating Error event then an Error event frame should be sent over 
the lu UP protocol indicating the appropriate error type. 
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6.7.4 Error event frame over the lu UP protocol 

When an Error event frame is received over the lu UP protocol an lu-Status-Indication with 'Error event' information 
indicating the error type should be made to the upper layers. The Error event report contains an 'Cause value' that tells 
the type of the error. The Error event report also contains a field 'Error distance' that tells the distance to the entity 
reporting the error event. The 'Error distance' is when the error is originally sent. When an Error event report is 
forwarded the 'Error distance' is incremented by one. 

6.7.5 Handling of error reports 



6.7.5.1 



General 



Figure 28 shows the external error case when the error event procedure is originally triggered by an lu-UP-Status- 
Request. As an action on this the error event procedure sends an error event frame over the lu UP. On the other side the 
reception of error event frame triggers the error event procedure, and an lu-UP-Status-Indication is sent to upper layers. 
The handling is symmetrical over the lu UP protocol. 



lu Interface 



status-Indication 

Error event 

(Cause, 

Error distance = 2) 



Support Mode \4- 
Functions 



Error event frame 

(Cause, 

Error distance = 1) 



Transfer of lu 

UP protocol 

frames 



status-Request 
Error event 
(Cause) 



Support Mode 
Functions 



Figure 28: External error 

Figure 29 shows the internal error case when the error event procedure is originally triggered by the lu UP functions. As 
an action on this the error event procedure sends an error event frame over the lu UP. On the other side the reception of 
error event frame triggers the error event procedure, and an lu-UP-Status-Indication is sent to the upper layers. The 
handling is symmetrical over the lu UP protocol. 
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lu Interface 



status-Indication 

Error event 

(Cause, 

Error distance=1 ) 



Support Mode 
Functions 



Error event fram^ 

(Causb, 

Error distance=0|l 



Transfer of lu 

UP protocol 

frames 



Status-Indication 

Error event 

(Cause, 

Error distance=0) 



Support Mode 
Functions 

Error detected! 



Figure 29: Internal error 
6.7.5.2 Error distance 

In an error event frame the error distance has the following meaning: 

0: Error report relates to an lu UP function error at the other side 

1 : Error report relates to an error at the other side reported by the upper layers 

In an lu UP-Status indication the error distance has the following meaning: 

0: Error report relates to an local lu UP function error 

1 : Error report relates to an lu UP function error at the other side 

2: Error report relates to an error at the other side reported by the upper layers 
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6.7.6 List of errors in lu UP 



Table 4: List of errors in lu UP 



Error Type 


Error Cause 


Recommended action 

by Error event 

procedure 


Possibly 

detected by 

function 


Comment 


Syntactical 


Bit error in Frame 
payload (CRC check) 


No action 


NAS data streams 
functions 


Handled by 
Frame Quality 
Classification, 
when applied 


Bit error in Frame Header 
(CRC check) 


lu-UP-Status- 
lndication(Error event) 


Frame handler 
functions 


Frame trashed 


Unexpected Frame 
Number 


lu-UP-Status- 
lndication(Error event) 


NAS data streams 
functions 




Frame loss 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


NAS data streams 
functions 




Unknown PDU type 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Frame handler 
functions 




Unknown procedure 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Frame handler 
functions 




Unknown or unexpected 
value 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Procedure control 
functions 




Frame too short 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Frame handler 
functions 




Missing fields 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Frame handler 
functions 




Semantical 


Unexpected PDU type 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Frame handler 
functions 




Unexpected procedure 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Frame handler 
functions 




Unexpected RFCI 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


NAS data streams 
functions 




Unexpected value 


lu-UP-Status- 
lndication(Error event) 
and Error event frame 


Procedure control 
functions 




Other error 


Initialisation failure 
(outside lu UP) 


Error event frame 


Function outside 
luUP 




Initialisation failure 
(network error, timer 
expiry) 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 




Initialisation failure (lu UP 
function error, repeated 
NACK) 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 




Rate control failure 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 




Error event failure 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 




Time Alignment not 
supported 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 




Requested Time 
Alignment not possible 


lu-UP-Status- 
lndication(Error event) 


Function outside 
luUP 




lu UP version not 
supported 


lu-UP-Status- 
lndication(Error event) 


Procedure control 
functions 
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6.7.7 Error detection 



6.7.7.1 



General 



Error detection is provided on frames through a Cyclic Redundancy Check. The CRC for the payload is 10 bits and for 
the header it is 6 bits. 

6.7.7.2 CRC Calculation 

The parity bits are generated by one of the following cyclic generator polynomials: 
gcRC6(D) = D" + D' + DV D' + D' + 1; 

gcRcio(D) = D'" + D" + D^ + DS D' + 1. 

Denote the bits to be protected of a frame by a^,a2,Cl^,...,a^(a^ being the bit with the highest bit position in the 

first octet), and the parity bits by p^, P2, p^,,---, Pi ■ Ai is the length of the protected data and L, is 6 or 10 depending 
on the CRC length. 

The encoding is performed in a systematic form, which means that in GF(2), the polynomial 
a,D^-^' +a2D^'^* +... + a^p' + p^D' + p^D' +...+ p,D' + p^ 
yields a remainder equal to when divided by gcRC6(D) and the polynomial 
• +a2D^ +... + a^D + p^D + P2D +... + pgD + Pi^ 

yields a remainder equal to when divided by gcRcio(D). If A; = , Pi = P2 — P3,—'" — Pl ~ ^ ■ 



6.7.7.3 



Relation between input and output of the Cyclic Redundancy Check 



The protected bits are left unchanged in the frame. The parity bits for the Header CRC are put in the Header CRC field 
with /)j being the highest bit position of the first octet of the Header CRC field. The parity bits for the Payload CRC are 

put in the Payload CRC field with p^ being the highest bit position of the first octet of the Payload CRC field. 

7 Communication Primitives for the lu UP protocol 

layer 

7.1 Modelling Principle 

The principle illustrated by figure 30 is used for modelling the primitives towards the protocol layer. 

REQUEST 




Figure 30: Modelling principle 
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7.2 Primitives towards the upper layers at the RNL SAP 



7.2.1 



General 



The lu UP protocol layer interacts with upper layers as illustrated in the figure above. The interactions with the upper 
layers are shown in terms of primitives where the primitives represent the logical exchange of information and control 
between the upper layer and the lu UP protocol layer. They do not specify or constraint implementations. 

The following primitives are defined: 

- lu-UP-DATA; 

- lu-UP-STATUS; 

- lu-UP-UNIT-DATA. 

Table 1 : lu UP protocol layer service primitives towards the upper layer at the RNL SAP 



Primitive 


Type 


Parameters 


Comments 


lu-UP-DATA 


Request 


lu-UP-payload 


Subflow 1 SDU, ..., Subflow n SDU 


lu-UP-control 


RFCI 


Indication 


lu-UP-payload 


Subflow 1 SDU, ..., Subflow n SDU 


lu-UP-control 


RFCI 


FQC 


lu-UP-Status 


Indication 


lu-UP-Procedure-Control 


Error Cause, Error Distance 


Initialisation 


RFCI indicators, 

Downlink send intervals (when 

applicable) 


Time Alignment 


Request 


lu-UP-Procedure-Control 


Error Cause 




Time Allignment ACK/NACK 


lu-UP-UNIT- 
DATA 


Request 


lu-UP-payload 




Indication 


lu-UP-payload 





Primitive usage is function of the mode of operation of the lu UP protocol. Table 2 provides the association between lu 
UP primitives towards the upper layers and the lu UP mode of operation. 

Table 2: lu UP protocol layer service primitives related to the lu UP mode 
of operation and function within the mode of operation 



Primitive 


Type 


Mode of Operation 


lu-UP-DATA 

lu-UP-Status 

lu-UP-UNIT- 
DATA 


Request 


SMpSDU 


Indication 


SMpSDU 


Request 


SMpSDU 


Indication 


SMpSDU 


Request 


TrM 


Indication 


TrM 
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7.2.2 lu-UP-DATA-REQUEST 

This primitive is used as a request from the upper layer lu NAS Data Stream entity to send the RAB subflow SDU(s) on 
the estabHshed transport connection. This primitive also includes the RFCI of the payload information included in the 
primitive. 

The lu UP Frame protocol layer forms the lu UP data frame, the lu Data Stream DU being the payload of the lu UP 
frame, and transfers the frame by means of the lower layer services. 

7.2.3 lu-UP-DATA-INDICATION 

This primitive is used as an indication to the upper layer entity to pass the lu NAS Data Stream User Plane information 
of a received lu UP frame. 

This primitive also includes the RFCI of the payload information included in the primitive. 

At the RNL-SAP, this primitive may include an Frame Quality Classification indication. 

This primitive may also include information aiming at informing the upper layers of a faulty situation that relates to the 
payload included in the primitive. 

7.2.4 lu-UP-STATUS-REQUEST 

This primitive is used to report that a fault has been detected. 

This primitive is also used for acknowledgement and negative acknowledgement of the timing alignment. 

7.2.5 lu-UP-STATUS-INDICATION 

This primitive is used to report to the upper layer entity that a fault has been detected. The information concerning that 
fault is characterised by the Abnormal event information passed to the upper layer. 

This primitive is also used in the context of the initialisation control procedure to pass to the upper lu DS layer e.g. the 
RFC set and the associated RFCIs to be used in the communication phase. 

This primitive is used to indicate to the upper layers the set of permitted rate(s) in the reverse direction over lu. The set 
of permitted rate(s) is represented by RFCI indicators and (when applicable) downlink send intervals. 

This primitive is also used to indicate when a frame has been dropped as a result of frame quality classification 
handling. 

This primitive is also used to indicate to the upper layers the Time alignment information, i.e. the amount of delay or 
advance the frame sending should be adjusted with. 

7.2.6 lu-UP-UNIT-DATA-REQUEST 

This primitive is used as a request from the upper layer to send an lu UP payload on the established transport 
connection. 

The lu UP protocol layer transfers the lu Data Stream DU by means of the lower layer services without adding any 
protocol header overhead. 

7.2.7 lu-UP-UNIT-DATA-INDICATION 

This primitive is used as an indication to the upper layer entity to pass the lu UP payload. 
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7.3 Primitives towards the transport layers at TNL SAP 

7.3.1 General 

Access to the Transport network Layer is performed through a generic SAP: TNL-SAP. 

When the Transport Network upper layer consists of AAL2, the TNL SAP maps onto the AAL-SAP through which 
communication is performed using specific AAL primitives. 

When the Transport Network upper layer consists of GTP-U, the TNL SAP maps onto the GTP-U SAP through which 
communication is performed using generic primitives. 

The choice of communication, specific or generic, through the TNL SAP is fixed by the Radio Network Layer control 
plane logic. This choice is based on the requirements placed by e.g. the RAB characteristics, the CN domain requesting 
the RAB establishment or other operator's choice. 

7.3.2 ATI\yi/AAL2 based Transport layer 



7.3.2.1 



General 



When the lu UP protocol layer uses the services of an ATM/AAL2 transport, it uses an established AAL2 connection 
for transferring frames between the peer TNL-SAPs at both end of the lu User plane access points. The Transport 
Network Control Plane over lu handles the signalling to establish and release the AAL2 call connections. 

7.3.2.2 AAL2 Service Primitives used by the lu UP protocol 

AAL2 services and primitives used at the Service Access Point from the AAL2 layer are shown in table 3. 

Table 3: AAL2 primitives and parameters 



Primitive 


Type 


Parameters 


Comments 


SSSAR- 
UNITDATA 


Request 


SSSAR-INFO 




SSSAR-UUI 


Not used (note) 


SSSAR- 
UNITDATA 


Indication 


SSSAR-INFO 




SSSAR-UUI 


Not used (note) 


NOTE: The setting of this field is set to not used i.e. decimal value 26 according to [8]. 



The primitives of table 3 are the standard primitives of [8]. These primitives are intended to be used in the lu UP. 

7.3.3 GTP-U based Transport Layer 



7.3.3.1 



General 



When the lu UP protocol layer uses the services of a GTP-U transport, it uses an established GTP-U tunnel for 
transferring frames between the GTP-U tunnel endpoints at both end of the lu User plane access points. The RANAP 
Control Plane signalling over lu handles the signalling to establish and release the GTP-U tunnels. 

7.3.3.2 Generic Service Primitives used by the lu UP protocol 

Generic primitives are used at the GTP-U SAP. They are shown in table 4. 
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Table 4: Generic primitives and parameters to and from GTP-U layer 



Primitive 


Type 


Parameters 


Comments 


lu-UP-UNITDATA 


Request 


lu-UP-payload 




lu-UP-UNITDATA 


Indication 


lu-UP-payload 





8 



Evolution of lu UP Protocol 



8.1 Principles for Protocol Evolution 
8.1.1 Unknown field value 

The lu UP protocol may be evolved by taking into use field values that have been specified to be reserved for future use 
or have been specified as spare values. When a UP protocol entity receives an unknown field value, it can react 
differently depending whether the unknown value is reserved for future use or if it is a spare value. The following 
principles are recommended for receiver reactions: 

if a spare value is used by the sender, but not understood by the receiver, there should be a default action for the 
receiver. This default action should be defined on a field basis; 

if a value that is reserved for future use is used by the sender, but not understood by the receiver, the value 
should be rejected by the receiver. This should be done by sending a Negative Acknowledgement to the peer 
entity, if possible. Otherwise an Error Event should be generated in order to inform the upper layers and the peer 
entity; 

a received Error Event message shall not trigger another Error Event message back to the sender, even though 
e.g. the Cause value in the received Error Event message would not be understood. 

In the following the recommended actions of the receiver are handled field by field when an unknown field value is 
received. 

PDU Type 

Recommended action if reserved values used: Generate Error Event, i.e. the upper layers and the peer entity are 
informed about the error event with Cause : Unknown PDU Type. 

FOG 

Recommended action if spare values used: Ignore the field and pass it onwards. 

ACK/NACK 

Proposed action if reserved values used: Generate an Error Event, i.e. the upper layers and the peer entity are informed 
about the error event with Cause : Unknown reserved value. 

Procedure Indicator 

Recommended action if reserved values used: Generate an Error Event, i.e. the upper layers and the peer entity are 
informed about the error event with Cause : Unknown procedure 

Error Cause value 

Value 49 is reserved for "lu UP version not supported" whatever the lu UP Mode version. 

Recommended action if reserved values used: Generate Error Event, i.e. the upper layers and the peer entity are 
informed about the error event with Cause : Unknown reserved value. 
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Recommended action if spare values used: Ignore the field and pass it onwards. 

8.1 .2 Adding a new field to an existing frame 

If there is a need to add a new field to an existing procedure, the following principles shall be applied: 

the PDU type defines the header mask. Therefore, a new field shall not be added to the header part of an existing 
frame and possible spare bits in the header shall not be taken into use since these would be violations of the 
header mask; 

the Procedure Indicator shall define the fields that should be in a control frame; 

there shall be only one Procedure Indicator for each procedure; 

if a new field needs to be introduced to an existing procedure (i.e. existing procedure that is defined in an 
existing UP version), the new field shall not be added to the payload part. Instead, the new field may be 
introduced by placing it to a spare field in the payload part of the frame, if possible; 

however, if a new field needs to be introduced to an existing procedure, but spare fields(s) in the payload part 
cannot be used to introduce the new field, then a new procedure shall be created and hence a new Procedure 
Indicator value shall be allocated for the new procedure; 

to enable simple protocol evolution, when a new Procedure Indicator will be introduced, the new frame shall 
include both the new fields and the fields of the old frame; 

when an implementation receives an unknown Procedure Indicator it may use the Error Event message with 
Cause: Unknown procedure to report this. This indicates to the sender that the procedure was not understood and 
it may try with an older procedure. 

8.1 .3 Adding a new PDU type 

In the future, the lu UP protocol may evolve so that there is a need to add a new PDU type. The criteria for introducing 
a new PDU type could be e.g: 

the Procedure Indicators may run out and there is a need to have more; 

there is a need to change the header mask, e.g. the Frame Number field may need to be increased or the CRC 
field needs to be modified. 

While the PDU type 15 is reserved for future PDU type extensions, there may be 'subtypes' under PDU type 15 in the 
future and there also may be new procedures in these 'subtypes'. 

Thus it has to be ensured that if the same Procedure Indicator value is used under several PDU types, it should be made 
clear e.g. in the Error Event cause element, which PDU type it concerns. 

The maximum length of the Spare Extension field is defined per PDU type. Thus when a new PDU type is added, an 
appropriate length for the Spare Extension field (if any) has to be defined. For Release '99, a length of 4 octets has been 
used for data PDUs, and 32 octets for control PDUs. 



8.1 .4 Protocol version handling 



In the future, new versions of the lu UP protocol may be introduced. A reason for a new version of the protocol could 

be, e.g: 

the earlier introduced new features or functions are required to be mandatory in the new version; 

due to technical development, the new version of the protocol could be totally different (and incompatible) from 
the earlier version. 

The following principles shall be applied to version handling of lu UP protocol: 

it shall be possible to introduce additional modes of operation; 

it shall be possible to evolve the operation modes independently of each other; 
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there shall be independent version numbers for each mode of operation; 

the mode of operation of an lu UP protocol instance is decided by the CN, but the version of the mode shall be 
negotiated between the CN and UTRAN during initialisation procedure; 

the version number of a UP operation mode may change or be unchanged between different releases; 

when the protocol is evolved it shall be made clear in the specification, which features belong to which versions; 

a new version may be an evolution (i.e. compatible) of the old version or the new version may be totally 
different from the old version. 

The structure of the PDU Type 14 header, up to and including header CRC, shall remain unchanged whatever 
the lu UP version. 
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Annex A (informative): 

Illustration of usage of RFC! for AMR speech RAB 

This annex contains information related to usage of RFCIs in the context of AMR speech RAB. 
The following figure illustrates the RFCI allocation and flow throughout the UTRAN. 
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1 . RAB Attributes: at RAB establishment or reconfiguration, the SDU size information parameter is passed 
to UTRAN. The SDU information is organised per BER i.e. RAB sub Flow. For instance,. 12,2 kbits/s AIVIR 
codec is passed as RAB sub flow 1 SDU size: 81 bits -class A bits-, RAB sub flow 2 SDU size: 103 -class 
B bits, as RAB sub flow 3 SDU size: 60 -class C-), which makes one RAB sub Flow Combination. This is 
done for all rates (i.e. all codec modes, DTX also if included). The lu UP is used in support mode for 
predefined SDU size. 

2. Allocation of RFCIs: the RNC dynamically allocates an identification (RFCI) to each permitted/possible 
combinations it can offer. E.g. for 12,2. kbits/s, the RNC allocates RFCI 3 (according to the example 
table A.I). 

3. Configuration of L2/3 based on RFCIs: RFCIs are used to configure the L23. RLC is used transparently. 
IVIAC configures its co ordinated DCHs with the RFCIs and associate one RFCI to one TFI. 

4. Initialisation of lu UP: the RNC reports the permitted combinations it can offer to the transcoder using an 
inband lu initialisation frame containing the RFCIs and associated RAB sub Flow sizes. 

5. Configuration of L2/3 based on e.g. TFCIs: idem as 3. L23 may use e.g. TFI to communicate with the 
Codec about the RAB sub-Flow structure of the SDU received or to be sent. 

6. RFCIS+ SDU size information: the RFCIs and associated RAB sub Flow sizes are received within the lu 
initialisation frame are passed to the Codec for configuration. 

7. Example of DL frame transfer: 

7.1 . The Codec encodes a 12,2 kbits/s frame. It sends down to the lu UP and SDU with an associated 
RFCI equals to 3 (in this example). 

The lu UP packs a frame with a header containing an RFCI set to value 3, and the payload made 
of the SDU received from the Codec. 

The lu UP passes to L23, the lu frame payload (the Codec SDU) and the RFCI. The L23 uses this 
RFCI to break the lu frame onto the co-ordinated DCHs corresponding to the different bits 
protection classes. The corresponding TFI is selected. 
The radio frame is sent with the TFCI chosen by IVIAC. 

The L23 receives the SDUs on the co-ordinated DCHs, combined them back and uses e.g. the 
TFCI to indicate to the codec the structure of the received frame. 



7.2. 



7.3. 



7.4 
7.5 



Figure A.I 

For information on RAB subflow combinations used for AMR speech see reference [12]. 

SRNC allocates one or more possible/available RAB sub-flow combination(s) and generates RAB sub-flow 
combination set. RAB sub-flow combination number is dynamically generated by SRNC. This RAB sub-flow 
combination set is signalled towards CN with user plane signalling as described in [1]. The signalling towards UE is to 
be defined by TSG-RAN WG2. 
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RAB sub-flow combination set: 

A RAB sub-flow combination indicator, RFCI, indicates which RAB sub flow combination will be used for the lu user 
frames. In the communication phase the RFCI is included in the user frame, and the RFCI state the structure of the user 
frame. 

Table A.l exemplifies the allocation of 4 different RAB sub-flows combinations for 3 sub-flows and generating of RAB 
sub-flows combination set. 

Table A.l : Example of Allocation of RAB sub-flows combination indicator 





RFCI 
(RAB sub- 
Flow 
Combination 
Indicator) 


RAB sub- 
Flow 1 


RAB sub- 
flow 2 


RAB sub- 
flow 3 


Total 


Source rate 


RAB 
sub- 
flows 
combina 
tion set 

















Source rate 1 


1 


39 








39 


Source rate 2 


2 


39 


56 





95 


Source rate 3 


3 


81 


103 


60 


244 


Source rate 4 


NOTE: In the table above the greyed area shows the part that Is sent In the Initialisation 
procedure In lu UP. This Is what constitutes the RAB subflow combination set. 
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Annex B (informative): 

Illustration of protocol states in the lu UP 

This annex contains information related to possible protocol states for operation of the lu UP. This annex does not 
constraint implementation and is for illustration purposes only. 

The state model is common for both ends of the lu UP so that the protocol machines are operating symmetrically. This 
approach is taken to facilitate state description for all cases including TFO and TrFO. 

NOTE: Primitive lu-UP-CONFIG-Req is used by upper layers to configure the lu UP protocol layer. It is used in 
this annex for illustrative purposes and therefore it is not defined in clause 7. 



B.1 Protocol state model for transparent mode 

Figure B.l illustrates the state model for transparent mode lu UP instances. A transparent mode instance can be in one 
of following states. 

lu-UP-CONFIG-Req 



lu-UP-UNIT-DATA-Req or 
lu-UP-UNIT-DATA-Ind or 
SSSAR-UNITDATA-Req or 
SSSAR-UNITDATA-Ind or 
lu-UP-UNITDATA-Ind or 
lu-UP-UNITDATA-Req 



lu-UP-CONFIG-Req 

Figure B.l : Protocol state model for transparent mode 



B.1.1 Null State 

In the null state the lu UP instance does not exist and therefore it is not possible to transfer any data through it. 

Upon reception of a lu-UP-CONFIG-Req from higher layer the lu UP instance is created and transparent mode data 
transfer ready state is entered. The mode information is received either through RANAP signalling or directly in the CN 
node. In the lu-UP-CONFIG-Req e.g. the following information will be indicated: 

transparent mode. 

B.1 .2 Transparent Mode Data Transfer Ready State 

In the transparent mode data transfer ready state, transparent mode data can be exchanged between the entities. 

Upon reception of lu-UP-CONFIG-Req indicating release from higher layer, the lu UP instance is terminated and the 
null state is entered. 



B.2 Protocol state model for support mode for predefined 
SDU sizes 

Figure B.2 illustrates the state model for support mode lu UP instances. A support mode instance can be in one of the 
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following states. 



luPDU 

Primitive between layers 

TBD 



lu-UP-CONFIGR&q^Initialisationjjjjjjgjig^fiQjj 

VRepeat) 



First PDU 

received or 

Initialisation 

Ack received 




lu-UP-CONFIGReq 



lu-UP-STATUSIndV 
(Rate control) 



Rate controP 
PDU 



lu-UP-DATAReqor 
lu-UP-DATAIndor 
SSSAR-UNITDATAReq or 
SSSAR-UNITDATAkid or 
lu-UP-UNITD ATAlnd or 
lu-UP-UNITDATAReq 



Figure B.2: Protocol state model for support mode 



B.2.1 Null State 

In the null state the lu UP instance does not exist and therefore it is not possible to transfer any data through it. 

Upon reception of a lu-UP-CONFIG-Req from higher layer the lu UP instance is created and initialisation state is 
entered. In the lu-UP-CONFIG-Req e.g. the following information could be indicated: 

support mode for predefined SDU sizes; 

time alignment (FFS); 

indication of delivery of erroneous SDUs; 

- periodicity. 

B.2.2 Initialisation State 

In the initialisation state the instance exchanges initialisation information with its peer lu UP instance. 

Upon reception of lu-UP-CONFIG-Req indicating release from higher layer, the lu UP instance is terminated and the 
null state is entered. 

Upon sending or receiving of an initialisation frame the lu UP instance remains in the Initialisation state. The sending 
side starts a supervision timer Tinit. The receiving side acknowledges the initialisation frame with a positive 
acknowledgement or a negative acknowledgement. The lu UP remains in initialisation state. 

Upon reception of an initialisation acknowledgement frame, the supervision timer Tinit is stopped and the lu UP 
instance enters SMpSDU data transfer ready state. 

Upon reception of a first PDU after sending a positive acknowledgement, the lu UP instance enters SMpSDU data 
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transfer ready state. 

Upon reception of an initialisation negative acknowledgement frame (INIT NACK) initialisation frame can be repeated 
n times. 

If after n repetitions, the initialisation procedure is unsuccessfully terminated (due to n negative acknowledgements or 
timer expires) the Error event procedure is used to report the Initialisation failure and the lu UP instance remains in the 
initialisation state. 

B.2.3 Support Mode Data Transfer Ready State 

In the support mode data transfer ready state, support mode data can be exchanged between the peer lu UP instances. 

Upon reception of lu-UP-D ATA-Request from the upper layer or SSSAR-UNITDATA-Indication or 
lu-UP-UNITDATA-Indication from TNL layer, appropriate user data transfer procedures are performed. lu UP instance 
remains in the SMpSDU data transfer ready state. 

Upon sending of lu-UP-DATA- Indication or SSSAR-UNITD ATA-Request or lu-UP-UNITD ATA-Request the lu UP 
instance remains in the SMpSDU data transfer ready state. 

Upon sending or receiving of a rate control PDU the lu UP instance remains in the SMpSDU data transfer ready state. 

Upon sending of a lu-UP-STATUS-Indication (rate control) the lu UP instance remains in the SMpSDU data transfer 
ready state. 

Upon reception of lu-UP-CONFIG-Req from higher layer the lu UP instance is terminated and the null state is entered. 

Upon detection of a protocol fault, lu-UP-STATUS-Indication is sent to upper layer an error event frame may be sent 
over lu UP. 

In case of handover or relocation, initialisation procedures may have to be performed and lu UP instance may have to 
enter the initialisation state. 
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Annex C (informative): 
Open Issues of the lu UP 

This annex contains information related to open issues left in the lu UP protocol. 
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